A programming error that leads to the abnormal termination of a program is called an error. When an error occurs, an exception may be generated (or “raised”). For example, an exception may be generated by an arithmetic logic unit or floating-point unit of a processor when an operation such as dividing by zero is detected or when an overflow or underflow condition occurs. An exception may also be generated by trying to execute an undefined instruction, or by privilege violations.
Today, when an application being debugged generates an exception, typically, a dialog box provides a message such as:                Warning! An unhandled exception of type “System.NullReferenceException” occurred in Application 24.exe.                    Additional information: Object reference not set to an instance of an object.                        OPTIONS: Break Continue Ignore Help        
This type of dialog fails the developer because the dialog is presented out-of-context from the code that generated the exception, making it difficult for the developer to fully understand what went wrong. Also, the choices presented by the dialog are confusing. It is not clear what distinguishes “Continue” from “Ignore”. The “Continue” option can be confusing because when this option is selected, the application may actually shut down. Typically, selecting the “Help” option launches a topic on using the dialog rather than a topic on how to handle the exception. Finally, the content of the dialog itself is parsimonious, confusing and does little to help the developer solve the problem in her code.
It would be helpful if a programming tool that addresses the above shortcomings were available.